This section will give you additional information you need to install and configure a certification authority (CA).
Before installing Certificate Services, you should plan the deployment of certification authorities (CAs) and public key infrastructure in your organization.
For more information about deploying a PKI, see Resources in public key infrastructure and Windows Deployment and Resource Kits.
If you are installing Certificate Services, there are a number of situations in which you may want to set up a CA. (The most typical is listed first here.)
After base setup has completed:
To install Certificate Services on a server that already has
For the procedures to set up a certification authority (CA) as part of the base setup, see Set up a certification authority.
As part of
Although Certificate Services is a service and is included with the
To install Certificate Services during the initial base installation of the
When you set up Certificate Services, you will be prompted for the following information:
During the Certificate Services installation, you can choose to set up any of the following types of certification authority (CA):
| Certification Authority Type | Description |
|---|---|
| Enterprise root CA | An enterprise root CA is a top-level CA in a certification hierarchy. An enterprise root CA requires the Active Directory directory service. It self-signs its own CA certificate and uses Group Policy to publish that certificate to the Trusted Root Certification Authorities store of all servers and workstations in the domain. Normally, an enterprise root CA does not directly provide resources for user and computer certificates, but is the foundation for a certificate hierarchy. For more information, see Enterprise certification authorities |
| Enterprise subordinate CA | An enterprise subordinate CA must obtain its CA certificate from another CA. An enterprise subordinate CA requires Active Directory. You use enterprise subordinate CAs when you want to take advantage of Active Directory, certificate templates, and smart card logon to |
| Stand-alone root CA | A stand-alone root CA is a top-level CA in a certification hierarchy. The stand-alone root CA may or may not be a member of a domain and, therefore, does not require Active Directory. However, it will use Active Directory if it exists for publishing certificates and certificate revocation lists. Since a stand-alone root CA does not require Active Directory, it can easily be disconnected from the network and placed in a secure area, which is useful when creating a secure offline root CA. For more information, see Stand-alone certification authorities |
| Stand-alone subordinate CA | A stand-alone subordinate CA must obtain its CA certificate from another CA. The stand-alone subordinate CA may or may not be a member of a domain and, therefore, does not require Active Directory. However, it will use Active Directory if it exists for publishing certificates and certificate revocation lists. It must obtain its CA certificate from another CA. |
Note
You may want to install a certification authority infrastructure within a defined security boundary and only allow specific computers to communicate with your certification authority. This means clients cannot connect directly to a CA to request and retrieve certificates. Or you may want to set up a CA that supplies certificates to Internet-based subjects. You may want to place a layer of insulation between these clients and the CA. Web enrollment allows these scenarios to be implemented easily.
Web enrollment is the component of a Microsoft CA that allows clients to submit certificate issuance and retrieval requests based on Web pages. It is installed when you install a Microsoft CA. It can also be installed on a non-CA computer to provide a Web front-end to your CA infrastructure on the back-end. In this configuration, clients make requests with the Web pages and only the computer that has Web enrollment installed needs to communicate with your CA.
For more information on installing Web enrollment, see Set up certification authority Web enrollment support.
If you select the Use custom settings to generate the key pair and CA certificate check box when you choose the type of CA to install, you can select the cryptographic service provider (CSP) to use. The CSP generates the public key and private key pair and performs cryptographic operations on behalf of the CA.
You can set the key length for the public key cryptographic keys that the CA uses to sign certificates. In general, the longer the key length, the more secure it is. Note that a longer key will take more time to generate during setup and longer to transmit on the network when building certificate trust lists.
You can also choose the message hash algorithm used by the CA, as well as specifying the use of existing cryptographic keys instead of generating new ones.
Note
For more information about smart card CSPs, see "Certificate Services and Public Key Infrastructure" at the Microsoft Windows Resource Kits Web site (http://www.microsoft.com/)
The following are some guidelines for completing the CA identifying information in Certificate Services setup:
| Field | Description |
|---|---|
| CA Name |
The name you want to give to the CA. You can enter a string using any Unicode character. The name of the CA will also be the common name of the CA's distinguished name in Active Directory. When special characters exist in the CA name, a sanitized CA name is used for operations that are unable to use the unmodified CA name. A CA's sanitized name is the name of the CA with all special characters encoded in a form that will allow them to be used for file names, CryptoAPI key container names, and Active Directory object names. Special characters are those characters that cannot be used in one or more of these names; the list includes all characters which are not ASCII characters and many ASCII punctuation characters. Further, Active Directory object names are limited to 64 characters by the Lightweight Directory Access Protocol (LDAP) standard. To accommodate this limit, Active Directory object names are constructed by truncating the sanitized name and appending a hash computed over the truncated part of the sanitized name. The distinguished name suffix field is automatically filled with the distinguished name of the Active Directory domain. If you edit this distinguished name, you must conform with the LDAP standard. Type certutil.exe at a command prompt without arguments to see the sanitized name for all of the published CAs. Type certutil.exe -v -ds to see all of the CA-related Active Directory names. The first column is a truncated CA name with the hash appended (the actual Active Directory object's container name, with special characters reverted back to their original form). A second column is displayed only if the truncated, sanitized name does not match the truncated CA name, and it is the actual Active Directory object's container name. |
| Distinguished name suffix | The X.500 distinguished name suffix that will be appended to the CA name. |
| Validity period | The length of time the CA's certificate should be valid. The CA will obtain a certificate that is valid for this length of time and use that certificate's private key for signing issued certificates and certificate revocation lists. |
Certificate Services uses local storage for its database, configuration data, backup data and logging data. You can specify locations for the database and log during CA setup. By default, the certificates issued by a CA are stored in:
For best performance, the database and log files should be kept on separate physical disk drives, preferably on separate disk controllers. This will maximize disk throughput and allow the CA to perform better.
You also have the option of specifying a shared folder when setting up a CA. The shared folder acts as a location where computer users can find information about certification authorities. This option is only useful if you are installing a stand-alone CA and do not use Active Directory.
If the host computer for Certificate Services is a member of a domain, information about the CA is automatically published to the Active Directory. However, the Active Directory does not act as the database for Certificate Services. This function remains with the local computer.
Note
When you set up a CA, you can add a CA policy statement to the CA certificate that is created during setup or a CA certificate renewal, in the form of text or a pointer to a Web site. The CA policy statement gives legal and other pertinent information about the CA and its issuing policies, limitations of liability, and so on. An end user will see this CA policy statement when they view the CA certificate and click Issuer Statement.
Here are the steps you need to follow to attach a policy statement to a CA's certificate:
The first two lines of CAPolicy.inf must be:
[Version]
Signature="$Windows NT$"
The next two lines of the file list the name of the policies for this CA. Multiple policies can be listed in Policies= if they are separated by commas. The name LegalPolicy is used here as an example, but the name can be whatever the CA administrator chooses when creating CAPolicy.inf:
[CAPolicy]
Policies=LegalPolicy
For each policy, you need to provide a user-defined object identifier (also known as an OID) and either the text you want displayed as the policy statement or a URL pointer to the policy statement. (The URL can be in the form of an HTTP, FTP, file, or LDAP address.) Continuing on with the example, if you are going to have text in the policy statement, the next three lines of CAPolicy.inf will read:
[LegalPolicy]
OID=1.1.1.1.1.1.1.1.1
Notice="Legal policy statement text"
If you are going use a URL to host the CA policy statement, the next three lines would instead read:
[LegalPolicy]
OID=1.1.1.1.1.1.1.1.1
URL="http://CompanyWebSite/CAPolicy/default.asp"
(Please note that the "OID=" entry used in this example is arbitrary and is shown only for illustrative purposes.)
In addition:
An example of multiple notices and URLs in a policy section might be:
[LegalPolicy]
OID=1.1.1.1.1.1.1.1.1
URL = "http://http.microsoft.com/somewhere/default.asp"
URL = "ftp://ftp.microsoft.com/somewhere else/default.asp"
Notice = "Legal policy statement text."
You can specify CRL Distribution Points (CDPs) in CAPolicy.inf. Note that any CDP in CAPolicy.inf will take precedence for certificate verifiers over the CDP's specified in the CA policy module. If you want to specify the CDP using CAPolicy.inf, a sample of the syntax is:
[CRLDistributionPoint]
URL="http://CompanyWebSite/Public/myCA.crl"
Some additional notes about the CRL section:
If no URLs are specified (in other words, if the [CRLDistributionPoint] section is empty), the default CRL Distribution Point extension will be suppressed.
You can specify the authority information access points in CAPolicy.inf. The syntax is:
[AuthorityInformationAccess]
URL="http://CompanyWebSite/Public/myCA.crl"
Some additional notes about the authority information access section:
If no URLs are specified (in other words, if the [AuthorityInformationAccess] section is empty), the default Authority Information Access extension will be suppressed.
Another optional section of CApolicy.inf is [EnhancedKeyUsage], which is used to specify Enhanced Key Usage extension object identifiers (also known as OIDs).
An example of this section is:
[EnhancedKeyUsage]
OID=1.2.3.4.5
OID=1.2.3.4.6
Another optional section of CApolicy.inf is [certsrv_server], which is used to specify renewal key length, the renewal validity period, and the certificate revocation list (CRL) validity period for a CA that is being renewed or installed.
An example would be:
[certsrv_server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=5
CRLPeriod=Days
CRLPeriodUnits=2
CRLDeltaPeriod=Hours
CRLDeltaPeriodUnits=4